\chapter{Mogelijke Uitbreidingen}
\label{cha:h6}
Door zich te verdiepen in een bepaalde probleemstelling komen nieuwe vragen te voorschijn. Je kan het vergelijken met een ballon. De kennis die je bezit zit in de ballon. Het raakvlak met de buitenwereld stelt de onopgeloste vragen voor. Bij het oplossen van deze vragen stijgt de kennis en wordt de ballon groter waardoor er nieuwe vragen aan bod komen.

Dit hoofdstuk beschrijft enkele open problemen of alternatieve oplossingen.% voor vragen die aan bod komen in deze thesis. Hier en daar met een oplossing die het probleem simpeler maakt of een probleem dat niet uitgewerkt is.% vind je meerdere oplossingen. Elke oplossing leidt op zich weer tot nieuwe problemen. %problemen krijg je een beter inzicht in de mogelijke oplossingen. Als iets beter verstaan wordt, rijzen er ook nieuwe vragen die de kennis opnieuw uitbreiden. 
%Door een probleemstelling beter te begrijpen stijgt het aantal nieuwe vragen exponentieel.
%Een antwoord op vraag reist meer vragen. Het aantal vragen stijgt exponentieel. 
 
\section{Beschikbaarheid van Dropbox}
Een onvermijdelijk probleem met de huidige implementatie is dat indien Dropbox wegvalt veel functionaliteit verdwijnt. De applicatie verwacht bij elke netwerktransactie een verbinding met Dropbox. Meestal wordt een link verzonden in plaats van het bestand zelf om te vermijden dat het bericht te groot wordt, dit kan bij smsen een kostelijke zaak worden voor de gebruiker.

Een mogelijke oplossing is deze gegevens op het internet verspreiden over meerdere aanbieders van cloud storage. Het algoritme zou analoog kunnen zijn aan een RAID (Redundant Array of Independent Disks) structuur~\cite{raid}. Redundantie van deze gegevens is ook een mogelijkheid door de gegevens op meerdere locaties in hun volledigheid op te slaan.

%Business klanten doelgroep SLA

\section{Alternatief Synchronisatie Private Sleutel}
In de huidige implementatie wordt AES in OCB mode gebruikt om de private sleutel via Dropbox te synchroniseren tussen de verschillende mobiele toestellen. 

Een alternatieve oplossing zou zijn dat per toestel een extra publieke sleutel gegenereerd wordt. Elk van deze publieke sleutels draagt bij tot de publieke sleutelring die hoort bij de gebruiker. Een vercijferd bericht zou dan moeten ge\"encrypteerd worden met elke publieke sleutel van deze contactpersoon.

Met deze nieuwe aanpak zal het gebruik van een server nodig zijn die het sleutelbeheer op zich neemt. Links gegenereerd door Dropbox API hebben een eindige levensduur. Een algoritme waar de verzender nakijkt of de publieke sleutel van de ontvanger nog up-to-date is, is dus onmogelijk met Dropbox omdat de link naar de publieke sleutel niet meer kan bestaan. Omgekeerd weet een gebruiker niet wie er allemaal zijn publieke sleutel bezit. Het is dus onmogelijk om bij elke update al deze individuen te contacteren met zijn nieuwe publieke sleutel.

\section{Alternatief Contacten Synchronisatie}

Het huidige synchronisatie-algoritme gebruikt \'e\'en bestand voor alle contacten. Deze oplossing heeft twee nadelen. Een eerste nadeel is dat bij elke update dit bestand moet gedownload worden. Als de gebruiker veel contacten heeft kan dit leiden tot veel datatrafiek.

Een tweede nadeel volgt uit het feit dat het contactenbestand informatie lekt over het aantal contacten. Elk contact neemt ongeveer evenveel bytes geheugen in. Een contact bestaat uit een identificatienummer, publieke sleutel en persoonlijke informatie zoals naam, telefoon,... Het aantal bytes dat een contact inneemt kan eenvoudig geschat worden wetende dat een identificatienummer en publieke sleutel altijd hetzelfde aantal bytes hebben. De overige informatie sommeert tot minder bytes. Een observator kan met deze kennis ongeveer schatten hoeveel contacten de gebruiker heeft. 

Een alternatieve oplossing zou zijn dit bestand te splitsen in \'e\'en bestand per gebruiker. Terwijl het nadeel van \'e\'en groot bestand vermeden wordt komt er een nieuw probleem te voorschijn, namelijk de benaming van de bestanden. Als naam zou de MAC van de inhoud of een deel van de inhoud zoals identificatienummer kunnen gebruikt worden. Een MAC wordt berekend met een cryptografische hashfunctie met sleutel.

Hiermee wordt het probleem niet vermeden dat het aantal contactpersonen gezien kan worden door een observator. Het is nu zelfs eenvoudiger. Een oplossing hiervoor zou kunnen zijn dat er op Dropbox altijd een vastgelegd aantal contactbestanden aanwezig zijn. Een observator zou dan geen verschil mogen zien tussen echte en valse contactbestanden. Elk contactbestand is dan ongeveer even groot. Lokaal op elk mobiel toestel wordt er een gegevensbank bijgehouden waarmee de valse contactbestanden kunnen onderscheiden worden van de echte. Zonder deze gegevensbank is het onmogelijk met een nieuwe contactpersoon en valse te overschrijven. De datum van de laatste wijziging zou geen informatie mogen vrijgeven over het aanmaken of wijzigen van een echte contactpersoon.
 
\section{Certificaten}
De OpenPGP standaard maakt gebruik van digitale certificaten die een identiteit aan een publieke sleutel verbinden. Deze certificaten, zoals vermeld in hoofdstuk~\ref{cha:h2} kunnen digitaal ondertekend worden door anderen. Het doel van deze digitale handtekeningen is om de correctheid van de informatie op het certificaat te bekrachtigen. De handtekeningen bewijzen echter niet de correctheid van de informatie op het certificaat maar tonen aan dat de tekenaars de informatie als correct beschouwen. 

In de gerealiseerde applicatie zijn deze certificaten niet aanwezig. De Spongy Castle API bevat methodes om certificaten aan te maken.
 

\section{OCB Mode op Java Card}

Voor een betere veiligheid dient een implementatie van het OCB algoritme aanwezig te zijn op de Java Card. Zoals eerder vermeld heeft de Java Card speciale structuren om deze sleutels veilig te bewaren tegen gekende software en hardware aanvallen. Momenteel kan de applicatie na invoeren van een pincode de private sleutel zonder vercijfering uitlezen. Terwijl de Android applicatie deze uitgelezen sleutel gebruikt, is er kans dat kwaadaardige applicaties deze sleutel kunnen stelen. Met integratie van de OCB mode zou op de Java Card de private sleutel enkel de kaart verlaten nadat deze vercijferd is. De code die de OCB mode implementeert is al aangepast om de aanwezige AES implementatie te gebruiken, zie deel~\ref{implcrypto}. Een poging tot conversie van deze Java code naar een applet is te vinden op~\cite{jcapplet}.


\section{B\`{e}taversie en Meer}

De applicatie is zo goed als klaar om naar de b\`{e}ta fase over te stappen. Hier en daar is nog ruimte om extra gebruikersinterface elementen toe te voegen. Zaken zoals rotatie van het scherm worden nog niet ondersteund. Het programma is enkel getest op froyo (2.2) en gingerbread (2.3.3) en maakt ook geen gebruik van toevoegingen in nieuwere versies van het Android platform. Bij aanvang van dit project was Android froyo de meest gebruikte versie. 

Voor de applicatie op de Google Play markt kan verdeeld worden, dient Dropbox de applicatie goed te keuren~\cite{dprelease}. Eenmaal deze laatste plooien glad zijn gestreken, zou een grotere testfase kunnen gestart worden door de applicatie te verdelen over de Google Play markt. En wie weet wat de toekomst nog brengt...% mee kan er hierna nog allemaal kan gebeuren.

%en wie weet wat er nog kan gebeuren.% welke pad wat er dan n